The 3rd Generation Partnership Project (3GPP) standard for the Universal Mobile Telecommunication System (UMTS) sets forth requirements for broadband packet-based transmission of different forms of data, including text, digitized voice, video and multimedia data at high transmission rates (i.e., up to 2 megabits per second (Mbps)). 3GPP UMTS allows for operating online media applications via mobile computers and/or conventional voice communication via wireless telephones from remote locations.
Specifically, 3GPP UMTS requires the calculation of a transport channel Bit Error Rate (BER) for turbo encoded data using this standard. The BER is calculated on the pre-decoded bits of a code block, excluding any punctured bits, which are removed in order to transmit more data using less bandwidth. Known systems for calculating the transport channel BER require additional processing after the time-consuming decode operation has been completed in order to provide the necessary calculations. With the high speed processing requirements of turbo decoders, and in particular at the maximum data rate of 2 Mbps, it is critical to calculate the transport channel BER at a data rate that minimizes processor time to reduce latency and thereby improve the efficiency of the communicating device. Minimizing processing time eases design constraints and also reduces power usage.
In order to compute the transport channel BER, the output of a decoder must be re-encoded and compared with the input data, excluding the punctured bits (i.e., bits removed before transmission). A major difficulty with this process is that turbo encoders for re-encoding must process data in both interleaved space and in linear space. This makes it impossible to stream the output of the decoder into the re-encoder, because two data streams are required. The need for two data streams results in a re-encoding process, that at best, could provide one half of the re-encode process in streaming mode and the other half after the decoder has finished its decoding operation. Such an approach may reduce the latency of the BER calculation. However, the output is generated in reverse order in interleaved space, which renders the above solution very difficult to implement. For example, it would be possible to use a stack to correct the reversed output, but the control of such a stack becomes very complicated due to a partially filled last window, thereby making this approach virtually impractical. Further, using a stack still does not solve the problem of fetching the decode results in linear order.
Further, in order to calculate the BER, data from different components within a turbo decoder are needed (e.g., for comparison), but are not always available for access. In particular, two sets of data are required, i.e., the input samples and the hard decision decode output, for calculating the BER. The memory buffers that contain this information have a single read port and shared access to this resource is necessary. It is very difficult to use spare processor bandwidth of the turbo decoder on a cycle by cycle basis to obtain input data for the BER calculation process. It is much easier to perform such calculations when other processes are idle. Also, because transport channel BER calculation requires the decode output twice (i.e., once in linear space and once in interleaved space), two passes of the output buffer are required to obtain the data from a single read port memory.